|
|
|
|
|
|
|
exception. This suggests the following rules for using dynamic strings inside structures. |
|
|
|
|
|
|
|
|
It is safe to use dynamic strings when |
|
|
|
|
|
|
|
|
The function you are calling expects a BSTR pointer in the structure (likely only with OLE DLL calls). |
|
|
|
|
|
|
|
|
You add a NULL character to the end of the string to be sure it is NULL-terminated. |
|
|
|
|
|
|
|
|
And if the DLL function modifies the string data, you initialize the string to the necessary length. |
|
|
|
|
|
|
|
|
It is not safe to use dynamic strings when: |
|
|
|
|
|
|
|
|
The DLL function modifies the value of the pointer inside the structure and is not using the OLE subsystem. This is typically the case if the pointer is anything other than BSTR *. Keep in mind that, outside the OLE subsystem, most API functions do not use BSTR variables, so you will rarely use dynamic strings inside structures used by the Win32 API. |
|
|
|
|
|
|
|
|
The Struct.vbp project defines the following structure, which is extremely similar to the one shown in the previous section: |
|
|
|
|
|
|
|
|
Private Type Struct2
a As Integer
b As Long
c As String * 4
d As String
End Type |
|
|
|
|
|
|
|
|
The cmdStruct2_Click function is almost identical to the cmdStruct1_Click function. The only difference is that the second structure field 'b' is set to &H56789ABC (since it's a 32-bit variable) and that the initial RtlMoveMemory call copies an extra 2 bytes into the temporary byte array (2 bytes beyond the length returned by the Len function). The reason for these 2 extra bytes will become apparent later. |
|
|
|
|
|